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event trending and correlation, and you get into data mining.
And then, of course, at the very high-end level,
you have organizations that are now starting to get into using artificial intelligence.
There are really three very popular methods of deploying intrusion detection.
The first is the network node-based intrusion detection,
which works very much like your regular network probe
in that it sits out on the network and it looks at the traffic.
However, it's deployed on a specific host,
and it only monitors traffic inbound to or outbound from that host.
Probably what most everyone is familiar with is the network-based intrusion detection,
where you would have a very inconspicuous probe sitting out on the network
that had a stealth interface and monitors an entire network segment.
And then, finally...
host-based intrusion detection, which is also deployed at the host
and monitors audit logs and things of that nature.
So, really, the pros that you get with the network node intrusion detection
is you're getting the benefit of having the network intrusion detection at the host.
It's unconcerned with bandwidth issues because it's not looking at the entire network.
And depending upon where in the stack encryption is,
you may be able to work against...
you may be able to work against some encryption.
Unfortunately, since it is network-based intrusion detection,
it really isn't telling you what the impact on the host is.
It's not telling you if critical system files were changed,
whether or not the system's vulnerable.
And then, of course, there's issues of scalability.
If you're going to...
if you're going to implement a piece of software out on each host in your network,
you're going to get into a situation where it may not...
you're going to get into a situation where it may not...
scale.
Network pros and cons.
I'm really, really torn on this
because I've worked with network-based intrusion detection for a number of years
and it's just failed me so many times.
But basically what you've got is the ability to...
ability to have something that's kind of more bang for your buck.
It goes and it monitors an entire network segment.
It has no fingerprint out on the network
so long as you're operating with a stealth interface.
And then you've got another management interface on another network.
The problem with this, once again,
is that it's unaware of whether or not an attack is successful.
Once you start getting into higher bandwidth,
it starts either dropping packets
or it's not fast enough to process everything it's seen.
So it may get all the packets,
but it's not detecting all of the exploits.
The host base, on the other hand,
is aware of what the system impact is.
And, of course, it's unconcerned with the bandwidth
because it has nothing to do with the network.
But once again,
now you're losing the network aspect
in that you're only looking at system audit logs and accounts.
And, of course, because it's limited to one host,
you get back into the scalability issues.
As far as variations of architecture are concerned,
there are really...
There are four.
And your first is your standalone.
And that would be something where you would have to go out
and individually or independently log into each monitor
that you had in order to extract the contents of it.
This is normally something that you would see
deployed in a very large...
I'm sorry, a very small environment
that didn't have money to spend.
And, of course, in this type of environment,
the event correlation becomes extremely difficult
because you don't have a centralized data repository
for everything to come back to.
Typically speaking, in a distributed system
where you have products such as ISS or Accent
or CyberSafe even for the host piece,
what you have is multiple agents reporting back to a command console.
And that command console can push down information
and it makes it easier to correlate events.
But the problem there is you've got a one-to-many relationship.
It's two-tiered.
It's not truly three-tiered.
And so you're only allowed to operate with one analyst
at a console at a time.
And so an ideally distributed environment
would be having many agents,
whether they be host, network, network node,
file integrity checking,
reporting back to a central data repository
and then having something such as a GUI client
sitting out at your analyst's desktop
so that they could easily log in
and pull all of that information.
And then, of course, I mention managed environments
because I used to work for a managed security service provider.
But basically here in this type of environment,
you have dedicated analysts who do this all of the time.
Those organizations are also held
to specific service level agreements
for response as well as data archiving.
There are certain economies of scale
because you are utilizing shared architecture.
And then, of course, it's minimal network overhead.
And then finally, you know, it's very distributed.
It gets back into talking about the shared architecture
and it's outsourced.
As far as architecture concerns,
with the network base,
you really need to worry about the bandwidth.
As we get into FASO,
it's going to be faster and faster networks.
A lot of the network intrusion detection vendors
tout that they can do 100 megabit or even faster.
And it's true that some of them are starting to get there.
But it's still an issue.
The faster the network,
the more resources it's going to consume and more difficult.
Scalability is also an issue
because when you're having numerous hundreds,
thousands of agents reporting back,
it can take up,
it can consume network overhead
as well as consume some of your resources.
Network fingerprint,
it's not really a concern for your network probes
that are out there
so long as you implement them with a stealth interface.
But you do see somewhat of a fingerprint with the host base.
And then, of course,
you want to ensure that you've got a reporting backend
so that you can gather all of this information
and produce something useful for management.
Not only to get more money for the initiative,
but also so that you can fine-tune the systems
that you have in place
and pinpoint where trouble spots are.
Oftentimes the,
oftentimes implementing intrusion detection
becomes segment specific
because it can be cost prohibitive.
Additionally, you need to look at the types of network traffic
that you're seeing,
especially when you want to implement network intrusion detection
on something such as a public services network.
Then you could really tune the system
to the types of network traffic,
types of network traffic that you've got
as well as operating systems
and the applications you have in play there
such as DNS or HTTP
and things along those lines.
There's a lot of debate as to where the best place
to deploy intrusion detection is concerned.
I will offer that you can deploy it
to watch the internet or extranet.
PSN is, many people refer to it as a DMZ,
but by the very nature of the word demilitarized zone,
it's saying that there's no control,
whereas most people have public services networks
where they have services such as web and DNS
and SMTP that is controlled.
So for the purpose of this presentation,
I'll just call it public services network.
Internal key network segments such as server,
farms, and then, of course,
anything on critical hosts,
you could implement the host-based
and the network node-based.
Really, when implementing on your external
or extranet segments,
you're kind of looking at suspicious activity detection.
This would be especially true
in looking at all of the information
that's hitting your firewall
and that's hitting your perimeter.
Some people would say that,
well, I've got the firewall to block all of this.
I don't need to see it.
But since I'm so paranoid,
I like to see everything that's coming in my network.
It's easier to deploy the network intrusion detection
on external and extranets,
unless, of course, you've got a DS3 or something.
But normally, these tend to be slower links,
and so you have lower throughput,
and the devices are able to keep up better.
Of course, it's not just for the Internet.
And then, as I was saying,
you know,
I put it outside of my firewall,
the Internet or extranet,
as kind of a catch-all
to see everything that's coming in.
The internal really depends on...
And when I say internal,
I'm talking about RFC 1918 addresses.
Oh, that's nice.
My battery's charged.
So I'm talking about the internal users
in your corporation or firm,
and it completely depends upon the threat model,
whether or not you want to monitor
what they're doing.
Some people choose that they want to do
event correlation with the external,
see what gets through the firewall,
and then compare the two.
Once again, that could be considered
a check and balance.
The way I like to use it
is not look at anything
coming into that particular network,
but watch everything that's going out
from that network
and see where my internal users are going.
Of course, on the internal network,
there's always a higher exposure to bandwidth.
Little technical difficulty.
Okay.
Your critical network segments
and public services networks.
Here is where you want to focus monitoring
on the systems themselves.
So that would mean implementing
host-based intrusion detection,
looking at key operating systems,
whether you've got, you know,
2000, Solaris, HPUX, AIX,
specific applications, the types of traffic.
You want to be able to narrow it down
as much as you can
because of the exposure to high bandwidth.
So this would be an excellent place
to implement host-based intrusion detection.
And then, of course,
we were talking about this earlier,
but generally speaking,
the way I like to implement intrusion detection
would be to watch everything
coming at my network from the internet,
kind of as a suspicious activity monitor,
watch everything coming in from my business partners
because my first responsibility
is to protect my own organization.
There are some legalities or ethical issues
related to ensuring that you're protecting
your business partners,
but my first concern is making sure
I'm protected from my business partners
as opposed to protecting my business partners
from anything else.
Additionally, as I mentioned earlier,
I like to watch everything
that's going out of my network.
And then, of course,
I like to watch things that go in and out of my DMZ
because I really don't want to see anything
initiating from my DMZ.
I only want to see it responding.
And, of course, I would put host-based agents
out on the servers on that particular segment.
As far as NIC configuration is concerned,
I had mentioned this a couple of times
earlier in the presentation,
so I'll cover it in depth now.
With network-based intrusion detection,
you really have three ways to go about configuring it.
There's the dual NIC configuration
with a stealth interface.
So, basically, you would give it an all-zero IP address
and then do an ARP minus S,
and you would end up having a stealth interface.
And then, on the other side,
you would have either, most likely,
an RFC 1918 address that went back to a monitoring network.
So, essentially, since there's no IPA stack
on the stealth interface,
it's operating in promiscuous mode,
and the device is essentially broken.
So, someone from the outside is not going to be able
to hack through that device
to get into your management network.
Another type of configuration would be
dual NIC without the stealth interface.
Maybe, perhaps, you want to look at
two different network segments
on your internal network,
and you think that the threat isn't such
that people will be trying to break the device.
And then the last would be
a single monitored managed interface.
So, you would be, basically,
you would be running in promiscuous mode,
but you'd also be using that
as your management interface to connect to the device.
It's important to start looking at false positives
once you get your intrusion detection
devices up and running.
It'll give you ideas on how to better design your solution
so that it's more intelligent.
It'll also allow you to better understand
the types of services and applications
you have running on your network.
And then, again, as I mentioned earlier,
it gives you the baseline of your performance
and then by which you can make adjustments.
And then, finally, really knowing your level of readiness.
So, where are you at as far as your security posture
is concerned and the types of things
that you have going on your network?
Data archival is extremely important.
Essentially, you have data being saved on the agent,
and then that agent is sent back to, hopefully,
a central repository.
This is the best place to put it,
to have all of your information resources,
all of your intrusion detection,
having that all come back to a central repository
because it eases event correlation.
It gives you an easier way to look at that information
and to make decisions about that.
It also allows you to make solid backups.
If all your information is in one place,
then it's much easier to backup
as opposed to running 15 different backups
or even hundreds of backups on agents every night.
And then, lastly, of course,
if you have this gigantic database,
it gives you the ability to run data mining tools
and to do some of the advanced event correlation
as well.
As well as perform some of the analysis.
Custom configuration is really...
What I'm getting at here is the ability to go in
and custom configure any type of misuse system.
You certainly don't want to buy a system
that's not going to allow you to go in
and use standard notation
and be able to fine-tune the device,
be able to enter in networks that you want to ignore
or wildcards, something along those lines,
because what invariably happens
is you get way too much information.
And when you have too much information,
it becomes overwhelming for analysts,
and then they just start ignoring it.
Additionally, it gives you added functionality and freedom,
and that comes back to reducing the information.
And finally, with the ad hoc security needs,
this would allow you to do something along the lines of,
create a signature that allowed you
to look at the subject line of an email
and then, of course, perhaps issue a TCP reset
to try and kill that session.
There are different types of custom attack signatures,
not getting too far into it,
but you have Unix scripting,
and a lot of that would be Snort,
proprietary languages, intrusion.com, SNP,
and so on.
You have EPL, NFR has ENCODE,
Accent has their own language as well.
Other products allow you to give a Windows-based interface
where you enter characters or wildcards,
something along those lines.
As far as tax signature creation,
you really have to be able to take an exploit
and compile it in your labs,
run the exploit, and capture packets.
And when you capture these packets,
then you can analyze them for what looks to be an anomaly and then of course when you do that
then you can begin to author the signature and the chosen language that you want and once you
write that then you can put it into your system and integrate it and see what happens here's an
example of what what I would call a Christmas tree attack and basically what that is is if you look in
the first 20 bytes of your IP packet where all your flags are at the Christmas tree attack which
is old and very basic would be having all of your flag set so you'd have your your urge and your act
and your push and reset and sin and Finn that's never supposed to happen in anything other than a
lab environment so in this particular case you would generate a packet that looked like this
and then capture packets using
you know ether real or whatever you'd like and then you would generate an attack signature that
looked for that specific activity and then of course this is a fairly generic example of a
snort signature basically you've got your rule header which is saying you want to alert anytime
you see a TCP packet that's sourced from and destined to the following and then of course
you use your rule options and so this is a this is a
a buffer overflow here Mount debuffer overflow
some things that people try and do for intrusion detection avoidance for some of the less robust
Solutions would be to uh well the example here is that the finite nature of attack signatures if
it's looking for root in a particular attack signature that's the way it's been programmed
then on the command line if you enter
um you know r03 times and then a backspace and then a tee well that doesn't exactly match what
it's looking for and that would be one way to a very simple way to uh to get around a system there
are still systems that are based like that that actually look at text rather than than context
um another thing most most products are I have actually progressed to the point where they're
they're fairly Adept at decoding hex I'm not each Natomiast auf Wieder
but for a very long time, products could not decode hex on the fly.
And so if you, the old IIS colon, colon, dollar data exploit,
if you wrote that out in hex, you could easily bring down an IIS server.
And then, of course, a lot of the products are becoming better with this as well,
but being able to reassemble TCP packets that are fragmented,
that used to be a very, very efficient way of getting around network-based intrusion detection.
And one of the products that did that very well was FragRouter by Doug Song.
And then, of course, we really need to think about usable reporting,
what types of reports are useful to us.
Are we looking for top talkers?
Are we looking for event by priority?
The types of things that become important to us,
are really independent based on one organization to the next.
And, of course, things to think about, how often do you want the reports?
I've seen reports run on a daily basis for event by priority,
and then, of course, kind of a weekly summary and even a summary, a monthly summary at times.
The key thing is really what do you do with these reports?
Oftentimes, you hand someone a report and they don't do anything with it.
So the daily reports.
The reports tend to be much more technical in nature where you give those to your analysts,
and they can go in and analyze traffic and make changes to the system.
And whereas your weekly summary reports are something that you would give to executive management
where they say, oh, my gosh, I can't believe that somebody tried to hack us and it was 500 times.
So, and, you know, the last thing is really are the reports read?
And oftentimes, I've found that they're not.
So when you put in pretty pictures, then executive,
usually read them incident response is something that goes hand in hand with intrusion detection.
So I'll just briefly talk about it here.
But you really need to have the policies in place.
Oftentimes, I've worked with clients to implement intrusion detection solutions.
And then something happens and they say, now what?
And they're really not sure what to do.
And so that's something that needs to be defined upfront before you get into,
incident response.
So the first thing that you need to do when you're installing the systems is having the policies in place.
And your incident response plan is an extension of your security plan.
It has everything to do with what's important to you in your security plan.
If you decide that you want to be notified every time someone fails their login three times,
then that's reacting to that as an extension of the security policy.
And, of course, that goes along with what do you do when you see specific traffic?
How do you rate the severity of an alert?
And then, of course, finally, possible data forensics.
Touching on event criticality briefly, it depends on a number of factors.
Most importantly, I would say your security policy and what you've deemed appropriate and important to you.
What types of intrusion detection that you have employed is going to determine the type of information that you receive back.
As far as security policy goes, that's going to depend on the type of information that you receive back.
as the different levels of an attacker concerned this gets back to the policy
this gets back to the types of operating systems and applications you have
running on your network you know what's important if you're if you are running
if you are running IIS and someone launches an Apache exploit against you
it's not going to be very important but if it were the other way around then all
of a sudden it would become pertinent so really this is a I would say that this
is probably my graphical stolen version of Northcutt's criticality metric in his
first book basically what you've got as far as criticality is concerned is
you've got your non-focused exploitable attack it's not really something that
you're interested in being notified about there's not much not much harm
that's going to happen of it so it may be
something that you want to report on or saving your systems in case there are
other related attacks for your
yeah absolutely if someone decides that they are going to if someone decides
that they're going to do a random netcast scan of your public services
network and all you have is Unix devices it's random so it's not focused and
second sure
so it's it's random and then the other thing is it's it's not something that's
exploitable number two it would be more reconnaissance work people that are
looking to gather information about your network they're digging on your DNS
they're doing you know they're doing and map scans they want to know what kind
of operating systems you have that's definitely something that's higher up on
the priority list and then of course when people start
jabbing at you you know it may be maybe random but it is something that could be
exploited on your network or the other way around it could be very focused but
not exploitable that's something where you really want to start watching what's
going on in your network in real time and then start possibly notifying people
in your escalation procedures or even a client if you're doing this for someone
finally actually not finally you have your focus
exploitable this is where you want to immediately contact the business unit
that would be responsible for this information resource certainly something
you want to be report on and then of course finally level five is extreme
danger focused you know that the system is vulnerable it very well could have
been compromised it looks that way judging from your host based intrusion
detection systems you want to immediately notify either the internal
or client contact and then begin to to perform either information incident
response or disaster recovery and then lastly just kind of throwing this in
here is really assessing what your needs are when you're choosing an intrusion
detection product there are products out there that are very expensive there are
products out there that are very expensive there are products out there
that are open-source that require a lot of time in coding and understanding so
how robust do you want it to be do you want to spend a lot of money and use
half the features or is it something that that you can get away with spending
less money and certainly demo the products being able to conduct all of
those comparisons to see the different types of things erecting a erecting an
intrusion detection lab is is not
It's not a huge feat, but it does require that a lot of different systems are in there
so that you can actually generate the bandwidth necessary
and be able to perform exploits on devices in there
so you can find out which systems are picking up and which systems aren't.
And then, of course, grill the vendors.
And that's it. Thanks.
Thank you.
Thank you.
